COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	What's this file all about?
C00003 00003	Exiting AL
C00006 00004	Log Book
C00007 00005	POINTY - QREAD redefining everything
C00009 00006	Does the Yellow Arm still work?
C00011 00007	AL/POINTY Discrepancy
C00015 ENDMK
C⊗;
What's this file all about?
 
Old pages will be moved to BBOARD.OLD[SYS,HE].
 
etc
Exiting AL
 
BIS - 27-Jun-79 - 0158
How do you get an AL program off the 11 ? I got my first AL program to run
tonight and it ran nicely.  The only problem is that the AL User's Manual
doesn't tell me how to exit from a DO AL[AL,HE].  A CALL will get my 10
task back, but it leaves the AL runtime code on the 11 and it leaves the
ELF assigned to me.  This causes two problems:  (1) unless I do a DEAS ELF
or logoff, I've still got the 11; and (2) any turkey who hits <alt>G on
the 11 will activate the AL program which I left there.  What should be
done?


MSM - 27-Jun-79 - 0936
One way is to zero out the memory of the 11 by doing a Z500000
to 11tty.  X gets you out of 11tty gracefully, but the only way
to deas elf is to do a DEAS ELF, or log out.

arg 6/27 10:30
When ever you finish using the arm you should ALWAYS turn off the arm's power.
Then it doesn't matter if some luser hits $G.  It also makes it impossible for
someone not at the hand-eye table to accidentally run a program that tries to
move the arm. So make a habit of pulling the yellow cord on your way out. As
to the 10 just call out of 11tty & deassign the elf (d elf). Many times we
keep the elf assigned for a long while while we debug some program (edit/compile
etc.). If someone else wants to use the elf you can be sure that they'll let you
know.


Log Book
 
BIS - 27-Jun-79 - 0158
Nobody ever seems to know whether the Zonker is working or not, so a log
book has been started to monitor such things.  If you attempt to use AL or
POINTY and the Zonker is either good or bad to you, please record this
fact along with date and time.  Only when we can really document that the
Zonker's flakey will we be able to get it properly serviced.  Other
suggestions?
POINTY - QREAD redefining everything
 
BIS - 27-Jun-79 - 0158
I performed a WRITE INTO file tonight with POINTY and then later did a
READ on that file.  The output file contained trillions of variable-value
pairs, only one of which had been defined by me.  Lots and lots of
variables had their values redefined during the READ, and I'm pretty sure
that this had undesirable effects, since a command to park the blue arm
took it into some spastic position in the center of the table with the
hand pointing up in the air; this was nicely repeatable.  Is it possible
that I redefined the position of BARM and that later move commands were
therefore misled?

MSM - 29-Jun-79 -1341
This happens to be a bug which I will fix up for the next version;
in the meantime do WRITE <var> INTO <file>, or if you like to live
dangerously do a DO POINTY[PNT,HE](2) which will run POINTY from
[PNT,MSM]
Does the Yellow Arm still work?
 
BIS - 27-Jun-79 - 0157
The blue arm hit the yellow arm at joint 2 tonight, knocking off a pair of
terminals (wires not broken, tho).  Did this have any other more serious
effect?

arg - You probably shouldn't have let that happen - i.e. if the yellow arm is
in its park position the blue arm can't hit it. Did you have your finger on the
panic button while you were running the arm???

bis - Yes, my finger was on the panic button, and I hit it as I saw what
was about to happen; unfortunately, the arm moved faster than I could.
The yellow arm is partially dismantled, so I don't know if it's in its
park position.  Why do you say that the blue arm *can't* hit the yellow
arm in park - software, hardware, or physical impossibility?  MSM tells me
that the blue arm didn't know its own position because of the singularity
at joint 4.
AL/POINTY Discrepancy
 
BS - 27-Jun-79 - 0300
TEST01.AL[AL,BIS] doesn't compile; it yields a "joints out of range" statement.
POINTY.IN[AL,BIS] is identical to it (omitting only BEGIN and END), but can
   successfully drive the blue arm as requested.
Why this discrepancy?
Also, TEST02.AL[AL,BIS] is identical to TEST01, but lacks a single statement
   (MOVE BARM TO DROP); it compiles OK.
What's going down here?


MSM - 27-Jun-79 - 0942
	The culprit is the MOVE BARM TO DROP statement.
AL allows default deproaches, POINTY does not currently know about
defaults.  If you had said MOVE BARM TO DROP DIRECTLY you wouldn't have
had the problem with AL.  The problem is that the approach point is high
above the surface of the table, and if you are trying to maintain the
arm orientation vertical, joint 5 will have to make an acute angle,
which it cant do because of geometrical constraints.

arg 6/27 11:00
The trajectory calculator bitching at you is not the same as your program not
compiling since you can continue from a "joints out of range error". Granted
that the associated error message isn't all that clear, but you might have
noticed that the error message said: "HAH!  This approach location is not
accessible." which should have pinpointed the problem somewhat. Then if you
had noticed that the expression printed out referred to DROP ("... (TVADD DROP
(VECTOR 0.0 0.0 3.0) ) ..." ) you would have known exactly what was wrong. By
the way you are not the first to be unknowingly caught by the sudden appearance
of default deproaches. We have had other complaints about them, but by and large
they seem to be a good thing and there are no plans to change them. Since they
do exist there is absolutely no need for the "MOVE BARM TO PICKUP + 5*ZHAT*INS"
statements. To correct your program then change "MOVE BARM TO DROP" to
"MOVE BARM TO DROP with approach = nildeproach".  Finally the first motion
statement in all of your programs should have a "with duration = 3*seconds"
clause so the arm has enough time to get there from wherever it last was left.